These new accepted Hub messages hook deeper into the updating lifecycle, as well as fixing issues where new firmware aren't sent to devices when an update is ignored or encounters errors.

This also moves the responsibility for rescheduling the update to Hub, which will resend the update shortly after the date sent by Link.

The new states sent to hub are:

• :updating (the progress is sent with this message)
• :finalizing (the download and applying of the update has finished and the device is about to reboot)
• :ignored (the device doesn't want the update. We could also allow a 'reason' to be sent)
• :reschedule (including the datetime to block device updates until)
• :error (something went wrong, a reason is also sent)

Two things to discuss/consider:

• I've changed the finalizing push to send a reply from hub, which allows us to make sure hub knows we are about to reboot, and thus track if a device updated by never came back online. I think, for consistency, we make all pushes to firmware_update_status return replies of :ok, and then its up to Link to decide if it cares about them or not.
• FWUP can send out info and warning messages (eg. https://github.com/nerves-project/nerves_system_rpi0/blob/main/fwup.conf#L292), but they are captured as 'warnings'. We could also send these up to Hub for extra data on how the update is going.

Some bits to track

• Update Hub to accept these messages (I have a changeset ready but we first need to merge in the new orchestrator)
• Test with some devices